Telephony application platform

ABSTRACT

A hosted private branch exchange (PBX) platform includes associated application programming interfaces (APIs) that provide a range of integration points with the PBX platform that, in turn, enables the development of a broad range of applications that can customize and/or enhance the basic functionality of the underlying PBX platform.

RELATED APPLICATION DATA

The present application is a continuation of and claims priority under35 U.S.C. 120 to U.S. patent application Ser. No. 14/468,751 entitledTelephony Application Platform filed on Aug. 26, 2014 (Attorney DocketNo. RINGP006C1), which is a continuation of U.S. patent application Ser.No. 13/930,406 entitled Telephony Application Platform filed on Jun. 28,2013 (Attorney Docket No. RINGP006), now U.S. Pat. No. 8,848,689. Theentire disclosures of both of the above-mentioned applications areincorporated herein by reference for all purposes.

BACKGROUND

Telephony services (e.g., voice and fax services) continue to evolve ata rapid pace with telephony platforms and application service providersproliferating on the Internet. The spectrum of service offeringsincludes hosted private branch exchange (PBX) platforms that provideenterprise-level telephony services, to hosted voice XML services thatprovide script-based call handing and/or voice mail functionality.Existing platforms provide some level of customization but such optionsdo not always keep pace with available options from third-partyproviders. However, making use of the options available from suchproviders can be difficult or inefficient to integrate with the providerof an enterprise's basic telephony service.

SUMMARY

Methods, systems, and computer program products are provided herein forproviding a wide range of telephony services in connection with aprivate branch exchange (PBX) platform. According to a particular classof implementations, the private branch exchange (PBX) platform isconfigured to provide telephony services to a plurality of independententerprises. Each of the enterprises has a plurality of users andextensions defined for that enterprise within the PBX platform. Aplurality of telecommunications interfaces are provided with a pluralityof independent telecommunications providers that facilitate at least aportion of the telephony services. One or more application programminginterfaces (APIs) enable a plurality of telephony applicationsassociated with different ones of the enterprises to integrate with thePBX platform at a plurality of integration points. The one or more APIsenable each of the telephony applications to access the users andextensions for the corresponding enterprise, and to control call flowsfor the corresponding enterprise during execution of the call flows bythe PBX platform.

According to some implementations, an application developer environmentis provided with which developers design first telephony applications ofthe plurality of telephony applications. The first telephonyapplications may be hosted by the PBX platform and/or at least some ofthe developers may also be users associated with one or more of theenterprises. Further, a telephony application store may be provided inwhich at least some of the first telephony applications are availablefor purchase by the enterprises. According to other implementations, thefirst telephony applications may be developed and hosted on one or moreother platforms independent of the PBX platform.

According to some implementations, the telecommunications interfacesinclude a stateless low-level interface that provides signaling andmedia telephony primitives, and a high-level interface that trackssession states and provides function building blocks for the telephonyapplications.

According to some implementations, the PBX platform may include anaccount data repository storing account data representing the users andextensions for each enterprise, a sessions data repository, a messagedata repository, and a call log data repository.

According to some implementations, the PBX platform communicates withclient devices using the Session Initiation Protocol (SIP).

According to some implementations, billing for use of one or more of thetelephony applications by one of the enterprises is integrated withbilling for use of the PBX platform by the enterprise.

A further understanding of the nature and advantages of variousimplementations may be realized by reference to the remaining portionsof the specification and the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1 and 2 are simplified diagrams of an example of a communicationsystem in which various implementations described herein may bepracticed.

FIG. 3 is a simplified block diagram of an example of a telephonyapplication platform employing techniques as described herein.

FIG. 4 includes flow diagrams illustrating incoming and outbound callsin the context of the telephony platform of FIG. 3.

DETAILED DESCRIPTION

Reference will now be made in detail to specific embodiments of theinvention including the best modes contemplated by the inventors forcarrying out the invention. Examples of these specific embodiments areillustrated in the accompanying drawings. While the invention isdescribed in conjunction with these specific embodiments, it will beunderstood that it is not intended to limit the invention to thedescribed embodiments. On the contrary, it is intended to coveralternatives, modifications, and equivalents as may be included withinthe spirit and scope of the invention as defined by the appended claims.In the following description, specific details are set forth in order toprovide a thorough understanding of the present invention. The presentinvention may be practiced without some or all of these specificdetails. In addition, well known features may not have been described indetail to avoid unnecessarily obscuring the invention.

This disclosure describes a hosted private branch exchange (PBX)platform with associated application programming interfaces (APIs) thatprovide a range of integration points with the PBX platform that, inturn, enables the development of a broad range of applications that cancustomize and/or enhance the basic functionality of the underlying PBXplatform. The APIs described herein provide these applications access tothe data of the PBX platform and allow them to execute telephonyfunctions on active calls while they are conducted by the PBX platform;handing control back and forth between the call flows being executed bythe PBX platform and the process flows created by applicationdevelopers. It should be noted that the following description employsthe terms “telephony service” and “telephony application” to refer tothe full range of services and functionality provided by PBX platforms;not just those related to voice communication.

Various implementations described herein may be implemented in or inconjunction with a cloud-based communication system such as the oneillustrated in FIGS. 1 and 2. FIG. 1 shows a communication system 100which can be, for example, a hosted PBX platform that provides voice andvideo over IP, fax services, etc. Communication system 100 includes datacenters 101, 102, and 103. Each data center is a point of presence (POP)that includes the network computing resources (e.g., servers, routers,switches, network connections, storage devices, etc.) necessary tosupport the services provided by communication system 100. Each datacenter is typically located in a different geographical region.

In this example, communication system 100 includes three user points ofdata (pods), i.e., pods 1, 2 and 3, each of which is a logical groupingof two or more pod units situated in different data centers. Each podserves a different subset of user accounts. In this example, each podunit (e.g., unit 2A) serves the same subset of users as the other podunits within the same pod (e.g., pod units 2B and 2C). Each pod unitincludes a communication server 119 a-119 g configured to providesubstantially the same services to the same subset of users as the otherpod units within the same pod. Each pod unit also includes an accountdatabase 121 a-121 g configured to support the respective communicationservers for the corresponding subset of users.

FIG. 2 shows various components of communication system 100 of FIG. 1.Specifically, FIG. 2 shows the various interconnections within andbetween data centers 101 and 102. Both data centers are in communicationwith network 217. Service requests from various communication devices243A-243D are routed through network 217 to either or both of the datacenters. Devices 243A-243D represent a great diversity of client devicesthat may connect with a services system designed in accordance with oneor more implementations as described herein. Such client devices mayinclude, for example (and without limitation), cell phones, smartphones, tablets, laptop and desktop computers, conventional telephones,IP phones, set top boxes, gaming consoles, etc. Reference to specificclient device types should therefore not be used to limit the scope ofthe invention.

Data center 101 includes pod units 1A and 2A, a common database (CDB)207A, a message storage system (MSS) 211A, a router 213A, and a globaluser directory (GUD) 215A. Additional pod units (not shown) may also beincluded in data center 101. Data center 102 is similarly configured andincludes components that operate substantially the same as those in datacenter 101. Data centers 101 and 102 provide backup and redundancy toone another in the event of failure.

Communication servers 119 provide telecommunication services (e.g.,voice, video, email, and/or facsimile) to corresponding subsets ofusers. Each server 119 may also provide other services including, forexample, user account management and configuration, billing services,accounting services, etc. Each pod unit includes an account database 121to support the communication server(s) for that particular pod unit,storing configuration details and other information regarding eachuser's account.

Pod units 1A and 1B are in communication with one another so that thedata on their respective account databases are synchronized across datacenters. Data center 101 includes router 213A to receive an incomingservice request 231A from network 217. Router 213A parses the incomingservice request to identify or extract a user key and queries GUD 215Ato determine which pod is associated with the user key. Once theassociated pod has been identified router 213A routes the servicerequest to the pod unit in the data center associated with theidentified pod. If the pod unit associated with the identified pod isnot associated with data center 101, router 213A may route the servicerequest to another data center (e.g., data center 102 as indicated bythe arrow 241A).

Each pod unit of the data center 101 is also coupled to MSS 211A whichstores files for the users served by pod units 1A and 2A. These filesmay include, for example, messages (e.g., voicemails and facsimiles),user logs, system messages, system and user call prompts (e.g.,auto-attendant or user-recorded greetings), and other types ofcall-related or electronic messages. The contents of MSS 211A aresynchronized with other data centers (e.g., synchronized with MSS 211Bof data center 102).

Each pod unit in data center 101 is coupled to common database 207Awhich stores shared data for all of the pods, and stores consolidatedinformation from account databases 121. Common database 207A alsofacilitates changes to the pod databases. For example, common database207A may store data for applications that provide the services oncommunication servers 119. Different versions of the applications datamay be stored in common database 207A which allow changes and upgradesto communication servers 119 to be implemented efficiently andconveniently. Changes may be made to common database 207A and propagatedto pod units 1A and 2A. Common database 207A is synchronized across datacenters to other common databases (e.g., common database 207B of datacenter 102). Common database 207A, MSS 211A, router 213A, and GUD 215Aform a common layer of resources that are shared by all pod units indata center 101.

For more information regarding the nature of such a system with whichvarious implementations described herein may be used, please refer toU.S. Patent Publication No. 2012/0134355 entitled User Partitioning in aCommunication System filed on May 31, 2012, the entire disclosure ofwhich is incorporated herein by reference for all purposes.

FIG. 3 is a simplified block diagram of an example of a PBX platform(e.g., such as communication system 100 of FIGS. 1 and 2) employingtechniques as described herein. PBX platform 300 provides telephonyservices that allow communication among its users, and between its usersand users associated with a variety of external telephony platforms 302via telecommunication APIs 304 and 306, Outbound SIP Proxy 308, andInbound SIP Router 310. Media Servers 309 and Fax Servers 311 providefunctionality for processing voice over IP and fax over IP data,respectively. Telco API 304 is a stateless low-level API that providessignaling and media telephony primitives including, for example, callanswering, placing of outbound calls, creation of conference callobjects, addition of calls to conference call objects, playback of mediafor active calls, recording of active calls, etc. Telco API 306 is ahigher-level API that has more sophisticated functionality such as, forexample, interactive voice response (IVR), call forwarding, voice mail,etc. In the depicted implementations, telco API 306 doesn't have accessto the PBX platforms databases, but maintains session context data 312to support its functionality. Telco API 306 may include functionprimitives which can be used to support the development of telephonyapplications as described herein.

Outbound SIP Proxy 308, and Inbound SIP Router 310 employ the SessionInitiation Protocol (SIP), an IETF-defined signaling protocol widelyused for controlling communication sessions such as voice and videocalls over the Internet Protocol (IP). SIP can be used for creating,modifying and terminating two-party (unicast) or multiparty (multicast)sessions, and may be one of the core protocols employed by systemsconfigured as shown in and described above with reference to FIGS. 1 and2. The latest version of the SIP specification is RFC 3261 from the IETFNetwork Working Group published in June 2002, the entirety of which isincorporated herein by reference for all purposes.

The core functionality of PBX platform 300 (e.g., as described abovewith reference to FIGS. 1 and 2) is accessed via telephony servicesblock 314 which has access (not entirely shown for clarity) to thevarious data repositories of PBX platform 300, i.e., account DB 316,sessions DB 318, call log DB, 320 and message DB 322. Telephony servicesblock 314 receives commands from telephony applications 324 and controlsexecution of the commands on the PBX platform 300. Telephony servicesblock 314 may also include internal telephony applications 325 that arehosted and/or developed on or in connection with PBX platform 300. Thedepicted implementation also includes various APIs that allow externaltelephony applications 324 to interact with PBX platform 300 asdescribed herein. The APIs associated with PBX platform 300 allowtelephony applications 324 and 325 to integrate with basic functionalityof PBX platform 300 at multiple integration points, to control callflows during execution of the call flows by the platform (e.g., via API326), and to access platform data (e.g., in DBs 316-322 via APIs328-334).

For example, the telephony applications may relate to a particularenterprise and might be integrated into call flows for that enterpriseat the point where a call is made or received (e.g., enforcing blockednumbers), the company greeting level (e.g., company directory), thedepartment level (e.g., call distribution), or at the individual level(e.g., call handling for individual extensions). And for eachintegration point, such applications can provide additional options,replace existing options, or augment existing options of the PBXplatform functionality. In addition, the script that embodies suchoptions can be hosted externally to the PBX platform, and hand controlof call flows back and forth with the platform.

As another example, a script may be created to make calls and playnotifications to customers, such as notifications that customer contactinformation has been changed. A script may also be created to execute asa call is received to determine whether the caller is on a user'sdynamic list of blocked numbers, and if so, to terminate the call. Ascript may be created to execute at the company greeting level to playdynamic customer alerts that are hosted on a user's own system and notthe PBX platform, such as customer-specific messages (e.g., based oncaller ID), holiday alerts, or dynamic advertisements. Other scripts maybe created at the company greeting level to enable a customized companydirectory, such as a company directory that uses natural languageprocessing to determine the correct department or individual to answerthe call (e.g., “How may I help you?” prompt) or a multiple levelinteractive voice response (“IVR”) menu. A script may be created toexecute at the department level to implement customized rules fordistributing calls, such as company-specific rules for selectingcustomer service agents from a queue. A script may be created to executeat the individual level to implement customized greetings, such as anunavailability greeting based on the individual's calendar or otherpresence information, or to implement customized call screening orvoicemail dialogs. The foregoing examples serve to illustrate the greatdiversity of telephony functionality that may be provided according tothe techniques describe herein.

A telephony application script may return control of a call flow back tothe application that called the script, such as the default applicationprovided by the PBX platform or a script that called the current script,either after the current script has executed or at any point in thecurrent script, such as upon the occurrence of a condition defined inthe current script. In some implementations, part or all of the defaultapplication provided by the PBX platform may be exposed as a script toallow for a large number of integration points and flexiblecustomization of the PBX platform.

According to a particular class of implementations, APIs having thefunctionalities described herein are implemented using the JavaScriptObject Notation (JSON) data format described in RFC 4627 dated July2006, the entirety of which is incorporated herein by reference for allpurposes. This class of implementations is also implemented inaccordance with at least some of the guiding principles embodied by theREST (REpresentational State Transfer) computing paradigm. The currentlyevolving notion of a “RESTful” system is based on the doctoraldissertion of Roy Thomas Fielding entitled Architectural Styles and theDesign of Network-based Software Architectures, University ofCalifornia, Irvine (2000), the entirety of which is incorporated hereinby reference for all purposes. Although there is, as of yet, no ratifiedstandard, a RESTful system generally observes a set of principles thatdefine how Web standards such as HTTP and URLs may be used to facilitateheterogeneous application-to-application communication. Generallyspeaking, REST relates to resource-based systems in which URLs refer tothe resources and HTTP methods are used to manipulate these resources.For additional information on RESTful systems, please refer to A BriefIntroduction to REST posted by Stefan Tilkov on infoq.com on Dec. 10,2007, the entirety of which is incorporated herein by reference for allpurposes.

According to a specific class of implementations, the APIs definespecific sets of responses for an application's various softwarecomponents to the HTTP methods. That is, the APIs define sets of rulesfor how they and the various software components with which theyinteract operate on the contents of a query for each of the differentmethods. According to a particular implementation, the HTTP methodsinclude the following:

“call”—Dial specified telephone number or SIP address

“conference”—Initiate or connect to specified conference

“end”—End current call

“if”—Define a condition (e.g., response, DTMF tone) to execute set ofcommands or script

“info”—Return session information (e.g., voice/fax/text, caller/accountID(s), to/from phone number(s), SIP address(es))

“play”—Play specified recording or phrase

“prompt”—Play specified recording or phrase and receive response

“record”—Record one or more channels of current call

“receive”—Initiate the receiving of fax, text, or other message dataover current call

“redirect”—Redirect incoming call to company, department, or individualuser (e.g., using name, phone number, extension, or SIP address)

“reject”—Reject incoming call

“result”—Return result of previous command (e.g., response to prompt,success/failure of command)

“script”—Run specified script

“send”—Send fax, text, or other message data over current call

“return”—Return control of call flow back to default or previousapplication

“transfer”—Transfer current call to company, department, or individualuser (e.g., using name, phone number, extension, or SIP address)

“wait”—Wait a specified period of time before continuing execution ofcall flow It will be understood that a wide range of other HTTP methodsmay be created or used, and that the foregoing list of HTTP methodsshould therefore not be used to limit the scope of the presentinvention.

Telephony applications 324 and 325 may provide a wide range of simple tohighly complex functionality that enhances, augments, or replaces thefunctionality provided by PBX platform 300. Examples of areas offunctionality include, but are not limited to, interactive voiceresponse functionality, call center functionality, call statisticsfunctionality, voice mail functionality, call blocking functionality,etc. In some implementations, media processing may be performed byservers hosted by telephony application developer and not PBX platform300, for example, to perform customized automatic speech recognition ornatural language processing for calls, after which control may be passedback to PBX platform 300, Virtually any telephony functionality that canbe imagined by developers and integrated with a PBX platform may besupported.

As mentioned above, telephony applications 325 may be developed and/orhosted on PBX platform 300. For example, platform 300 may include anapplication developer environment (not shown) in which developers (whomay be agents of, the platform provider, existing platform customers, orindependent developers) design and deploy telephony applications.Alternatively, telephony applications 324 may be developed and/or hostedon other platforms independent of PBX platform 300. PBX platform 300 mayalso include a telephony application store (not shown) in whichtelephony applications (e.g., 324 and/or 325) are made available forpurchase to customers of PBX platform 300.

According to some implementations, the telephony application store canoffer advanced billing and analytics functionality based on thetelephony applications' integration with PBX platform 300. Whiletraditional application stores provide fixed billing based on apurchased application, the telephony application store may providealternative billing based on the purchasers of telephony applicationswho may also be PBX platform subscribers. For example, the telephonyapplication store may provide subscription billing corresponding tosubscription billing for PBX platform 300, customized billing based onthe number of individuals (e.g., employees of an enterprise customer)under a user account (e.g., a company account) or the number oftelephone numbers under a user account, or usage billing based on usageof the telephony application or PBX platform 300 (e.g., number ofcallers, minutes used, storage used). In addition, because the telephonyapplications may be based on API calls processed by the PBX platform, atelephony application store integrated with PBX platform 300 can offeradvanced analytics detailing usage of the telephony applications, suchas call flow statistics and caller statistics.

FIG. 4 includes flow diagrams illustrating incoming and outbound callsin the context of the telephony platform of FIG. 3. In particular, FIG.4(a) illustrates handling of an incoming call by a PBX platform (e.g.,300 of FIG. 3) in conjunction with an external telephony application(e.g., 324 of FIG. 3), while FIG. 4(b) illustrates handling of anoutbound call in conjunction with an external application. It will beunderstood that the flows for handling of such calls for internaltelephony applications (e.g., 325 of FIG. 3) is similar to the depictedflows and will therefore not be separately discussed.

The flow diagram of FIG. 4(a) illustrates an example in which a greetingis played for the calling client device. The call from the client (402)is received by an SIP or media server (e.g., 308 of FIG. 3) which handsthe call off (404) to an API server (e.g., 326 of FIG. 3). The APIserver makes a session call (406) to a telephony application (e.g., 324of FIG. 3) according to call handling rules associated with theextension to which the call is directed. The telephony application makesone or more calls to platform databases (408) (e.g., 316 of FIG. 3) viathe corresponding API (e.g., 328 of FIG. 3) to obtain setting data(e.g., company, department, or individual settings or data, such asendpoint addresses or custom recordings) which, when obtained (410), ituses to generate application script. The script is then passed back(412) to the API server for execution, i.e., in this example, playbackof a greeting (414), that is passed back to the client (416) by the SIPor media server.

The flow diagram of FIG. 4(b) illustrates an example in which a call toa client device (e.g., an automated calendar reminder) is generated. Inthis example, the application makes a call (452) to the API server tocreate a session (454). As in the previous example, the applicationmakes one or more calls to platform databases (456) to obtain settingdata (458) which it uses to generate application script. The script ispassed back (460) to the API server for execution, i.e., in thisexample, the call to the client device (462), that is then established(464) by the SIP or media server.

As will be appreciated by those of skill in the art, because APIsimplemented as described herein allow a deep level of integration withan underlying PBX platform, application developers have the ability toextend the functionality of the platform in a manner which can beseamless for customers of the PBX platform. For example, call centerfunctionality for an enterprise may be established without having tocreate users in the context of the call center application or withouthaving to establish a billing relationship between the enterprise and acall center provider, i.e., the enterprise already has users definedwithin the PBX platform, as well as a billing relationship that can bereadily integrated with the call center functionality. It should benoted, however, that API implementations are contemplated which allowdevelopers to specify additional parameters for existing accounts,users, extensions, etc., to support the functionality provided by theirapplications.

APIs implemented as described herein allow independent developers toprovide telephony applications that access and enhance the functionalityof the same underlying PBX platform. And such applications may be usedby independent customers of the PBX platform to customize the telephonyservices provided by the platform in a manner which best suits the needsof each customer and, at least in some cases, to achieve that in aseamless manner.

It should be noted that, despite references to particular computingparadigms and software tools herein, the computer program instructionswith which embodiments of the invention may be implemented maycorrespond to any of a wide variety of programming languages, softwaretools and data formats, and be stored in any type of volatile ornonvolatile, non-transitory computer-readable storage medium or memorydevice, and may be executed according to a variety of computing modelsincluding, for example, a client/server model, a peer-to-peer model, ona stand-alone computing device, or according to a distributed computingmodel in which various of the functionalities may be effected oremployed at different locations. In addition, reference to particularprotocols herein are merely by way of example. Suitable alternatives orthose later developed known to those of skill in the art may be employedwithout departing from the scope of the invention.

While the invention has been particularly shown and described withreference to specific embodiments thereof, it will be understood bythose skilled in the art that changes in the form and details of thedisclosed embodiments may be made without departing from the spirit orscope of the invention. In addition, although various advantages,aspects, and objects of the present invention have been discussed hereinwith reference to various embodiments, it will be understood that thescope of the invention should not be limited by reference to suchadvantages, aspects, and objects. Rather, the scope of the inventionshould be determined with reference to the appended claims.

What is claimed is:
 1. A platform, comprising one or more computingdevices deployed in a network computing environment, the one or morecomputing devices being configured to provide services to a plurality ofindependent enterprises, each of the enterprises having account datastored in one or more data stores of the platform, the one or morecomputing devices implementing one or more application programminginterfaces (APIs) that enable each of a plurality of applications tointegrate with the platform, different subsets of the applications beingdeveloped by corresponding ones of a plurality of third party providerseach of which is independent of the platform, the one or more APIsenabling each of the applications to access the account data forsubscribing ones of the enterprises, and to control processes for thesubscribing enterprises during execution of the processes by theplatform, thereby extending the functionality of the platform for thesubscribing enterprises.
 2. The platform of claim 1, wherein the one ormore computing devices are further configured to provide an applicationdeveloper environment with which developers design first applications ofthe plurality of applications.
 3. The platform of claim 2, wherein theone or more computing devices are further configured to host the firstapplications.
 4. The platform of claim 2, wherein the one or morecomputing devices are further configured to provide an application storein which at least some of the first applications are available forpurchase by the enterprises.
 5. The platform of claim 1, wherein firstapplications of the plurality of applications are developed and hostedon one or more other platforms independent of the platform.
 6. Theplatform of claim 1, wherein the platform has a plurality of clientdevices for which the platform provides the services, and wherein theplatform communicates with the client devices using the SessionInitiation Protocol (SIP).
 7. The platform of claim 1, wherein billingfor use of one or more of the applications by one of the enterprises isintegrated with billing for use of the platform by the enterprise. 8.The platform of claim 1, wherein the platform is a private branchexchange platform, and wherein the applications are telephonyapplications that relate to one or more of interactive voice responsefunctionality, call center functionality, call statistics functionality,voice mail functionality, or call blocking functionality.
 9. Theplatform of claim 1, wherein the platform is a private branch exchangeplatform, wherein the applications are telephony applications, andwherein the account data for each enterprise represent a plurality ofusers and extensions defined for that enterprise within the PBXplatform.
 10. A computer-implemented method for extending functionalityof a platform for a plurality of independent enterprises, comprising:providing services to the enterprises via the platform deployed in anetwork computing environment, each of the enterprises having accountdata stored in one or more data stores of the platform; providing one ormore application programming interfaces (APIs) that enable each of aplurality of applications to integrate with the platform, differentsubsets of the applications being developed by corresponding ones of aplurality of third party providers each of which is independent of theplatform; enabling each of the applications to access the account datafor subscribing ones of the enterprises; and enabling each of theapplications to control processes for the subscribing enterprises duringexecution of the processes by the platform.
 11. The method of claim 10,further comprising providing an application developer environment withwhich developers design first applications of the plurality ofapplications.
 12. The method of claim 11, further comprising hosting thefirst applications with the platform.
 13. The method of claim 11,further comprising providing an application store in which at least someof the first applications are available for purchase by the enterprises.14. The method of claim 10, wherein first applications of the pluralityof applications are developed and hosted on one or more other platformsindependent of the platform.
 15. The method of claim 10, wherein theplatform has a plurality of client devices for which the platformprovides the services, and wherein the platform communicates with theclient devices using the Session Initiation Protocol (SIP).
 16. Themethod of claim 10, further comprising integrating billing for use ofone or more of the applications by one of the enterprises with billingfor use of the platform by the enterprise.
 17. The method of claim 10,wherein the platform is a private branch exchange platform, wherein theapplications are telephony applications that relate to one or more ofinteractive voice response functionality, call center functionality,call statistics functionality, voice mail functionality, or callblocking functionality.
 18. The method of claim 10, wherein the platformis a private branch exchange platform, wherein the applications aretelephony applications, and wherein the account data for each enterpriserepresent a plurality of users and extensions defined for thatenterprise within the PBX platform.
 19. A computer program product forextending functionality of a platform for a plurality of independententerprises, the computer program product comprising one or moreapplication programming interfaces (APIs) for use with the platform, theplatform being deployed in a network computing environment andconfigured to provide services to the enterprises, each of theenterprises having account data stored in one or more data stores of theplatform, the computer program product comprising one or morenon-transitory computer-readable media having computer programinstructions stored therein, the computer program instructions beingconfigured such that, when executed by one or more computing devices,the computer program instructions cause the one or more computingdevices to: enable each of a plurality of applications to integrate withthe platform, different subsets of the applications being developed bycorresponding ones of a plurality of third party providers each of whichis independent of the platform; enable each of the applications toaccess the account data for subscribing ones of the enterprises; andenable each of the applications to control processes for the subscribingenterprises during execution of the processes by the platform.
 20. Thecomputer program product of claim 19, wherein the computer programinstructions are further configured to provide an application developerenvironment with which developers design first applications of theplurality of applications.